A storage system typically comprises one or more storage devices into which information may be entered, and from which information may be obtained, as desired. The storage system includes a storage operating system that functionally organizes the system to by, inter alia, invoking storage operations in support of a storage service implemented by the system. The storage system may be implemented in accordance with a variety of storage architectures including, but not limited to, a network-attached storage environment, a storage area network and a disk assembly directly attached to a client or host computer. The storage devices are typically disk drives organized as a disk array, wherein the term “disk” commonly describes a self-contained rotating magnetic media storage device. The term disk in this context is synonymous with hard disk drive (HDD) or direct access storage device (DASD).
The storage system may be further configured to operate according to a client/server model of information delivery to thereby allow many clients to access data containers, such as files and logical units, stored on the system. In this model, the client may comprise an application, such as a database application, executing on a computer that “connects” to the storage system over a computer network, such as a point-to-point link, shared local area network (LAN), wide area network (WAN), or virtual private network (VPN) implemented over a public network such as the Internet. Each client may request the services of the storage system by issuing file-based and block-based protocol messages (in the form of packets) to the system over the network.
A plurality of storage systems may be interconnected to provide a storage system cluster configured to service many clients. Each storage system or node may be configured to service one or more volumes, wherein each volume stores one or more data containers. Communication among the nodes involves the exchange of information between two or more entities interconnected by communication links. These entities are typically software programs executing on the nodes. The nodes communicate by exchanging discrete packets or messages of information according to predefined protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other.
Each node generally provides its services through the execution of software modules, such as processes. A process is a software program that is defined by a memory address space. For example, an operating system of the node may be implemented as a single process with a large memory address space, wherein pieces of code within the process is provide operating system services, such as process management. Yet, the node's services may also be implemented as separately-scheduled processes in distinct, protected address spaces. These separate processes, each with its own process address space, execute on the node to manage resources internal to the node and, in the case of a database or network protocol, to interact with users.
Services that are part of the same process address space communicate by accessing the same memory space. That is, information exchanged between services implemented in the same process address space is not transferred, but rather may be accessed in a common memory. However, communication among services that are implemented as separate processes is typically effected by the exchange of messages. For example, information exchanged between different addresses spaces of processes is transferred as one or messages between different memory spaces of the processes. A known message-passing mechanism provided by an operating system to transfer information between process address spaces is the Inter Process Communication (IPC) mechanism.
Resources internal to the node may include communication resources that enable a process on one node to communicate over the communication links or network with another process on a different node. The communication resources include the allocation of memory and data structures, such as messages, as well as a network protocol stack. The network protocol stack, in turn, comprises layers of software, such as a session layer, a transport layer and a network layer. The Internet protocol (IP) is a network layer protocol that provides network addressing between nodes, whereas the transport layer provides a port service that identifies each process executing on the nodes and creates a connection between those processes that indicate a willingness to communicate. Examples of conventional transport layer protocols include the reliable connection (RC) protocol and the Transmission Control Protocol (TCP).
Broadly stated, the connection provided by the transport layer, such as TCP, is a reliable, securable logical circuit between pairs of processes. A TCP process executing on each node establishes the TCP connection in accordance with a conventional “3-way handshake” arrangement involving the exchange of TCP message or segment data structures. The resulting TCP connection is identified by port numbers and IP addresses of the nodes. The TCP transport service provides reliable delivery of a message using a TCP transport header. The TCP protocol and establishment of a TCP connection are described in Computer Networks, 3rd Edition, particularly at pgs. 521-542, which is hereby incorporated by reference as though fully set forth herein.
Messages passed between nodes of a cluster are typically implemented as remote procedure calls (RPCs). One format for RPCs is defined in Request for Comments 1831, entitled RPC: Remote Procedure Call Protocol Specification Version 2 by R. Srinivasan dated August 1995, the contents of which are hereby incorporated by reference. Generally a RPC comprises a header portion and a set of procedure specific parameters. The procedure specific parameters may include a set of control information and data associated with the message.
In systems using RPCs, it is desirous that data is secure and not vulnerable to a network security attack. The Generic Security Service application program interface (GSS-API), described in Request for Comments 2078, entitled Generic Security Service Application Program Interface, Version 2, by J. Linn dated January 1997, the contents of which are hereby incorporated by reference, provides a set of security services in a generic fashion for a variety of transport mechanisms. The GSS-API defines its services and primitives independently of the underlying transport mechanism and/or programming language environment.
To utilize the GSS-API within a RPC protocol environment, the RPCSEC_GSS protocol, defined in Request for Comments 2203, entitled RPCSEC—GSS Protocol Specification, by M. Eisler dated September 1997 and hereby incorporated by reference, is to typically employed. The RPCSEC_GSS protocol defines a variety of levels of protection including an Authentication level and an Integrity level. In the Authentication level, the credential within a message is hashed and then encrypted to form an Authentication verifier. In the Integrity level, a hash is executed over the procedure specific parameters contained within a RPC and the resulting hash value is encrypted to produce a message verifier, which is then appended to the RPC.
However, a disadvantage associated with both of these protection levels involves the computational overhead required to perform the necessary calculation. For example, the entire procedure specific parameters section, including any data contained therein, must be hashed in the Integrity level. This introduces substantial overhead in terms of time as well as a concomitant reduction in available processing resources for performing other tasks. Moreover, this additional overhead may result in additional latency when retrieving data in a storage system environment.